Operationalisierung der IT-Governance-Kernbereiche für die Identifizierung und Gestaltung von Services

Serviceorientierung ist ein seit einigen Jahren viel diskutiertes Paradigma für Unternehmensarchitekturen. Ein wichtiger Erfolgsfaktor für die Implementierung einer serviceorientierten Architektur (SOA) ist die Berücksichtigung der fachlichen Perspektive basierend auf Geschäftsprozessen [DD07]. Zu dieser fachlichen Sicht auf eine SOA gehören auch Governance-Aspekte, weshalb analog zur IT-Governance der noch recht unpräzise Begriff SOA-Governance geprägt wurde. Ein Bestandteil der SOA-Governance ist, nach Ansicht der Verfasser, die ServiceGovernance, d.h. die fachliche Sicht auf den einzelnen Service. Notwendig sind demnach Verfahren, die eine Berücksichtigung der Governance-Perspektive bereits zu einem frühen Zeitpunkt im Service-Lebenszyklus ermöglichen. Ziel dieses Beitrages ist daher die Entwicklung eines Fragebogens, zur methodischen Unterstützung der Identifikation und Gestaltung von Services. Hierfür wurden aus den fünf Kernbereichen der IT-Governance, den sogenannten IT Governance Focus Areas, Dimensionen der Service-Governance abgeleitet und für eine Verwendung während der Service-Identifikation operationalisiert. 1 Governance in serviceorientierten Architekturen Nur Unternehmen mit der Flexibilität, sich schnell an ein neues Marktumfeld anzupassen, können langfristig überleben [BKR04]. In diesem Zusammenhang ist die Serviceorientierung ein viel genanntes Paradigma für die Unternehmensarchitektur. Die in Verbindung mit Serviceorientierung am häufigsten genannten Aspekte sind eine schnellere Anpassung an Veränderungen der Geschäftsprozesse durch eine größere Flexibilität und Agilität, eine höhere Wiederverwendbarkeit von Services und die lose Kopplung verbunden mit einer hohen inneren Kohäsion der Services [Pa03]. Die Wiederverwendbarkeit von Services verhindert das unnötige Vorhalten redundanter Funktionen und senkt somit Entwicklungsund Unterhaltungskosten der IT-Infrastruktur. Die lose Kopplung ermöglicht eine nahezu virtuose Komposition von Services und eröffnet SourcingPotentiale, bspw. durch die Nutzung von Web-Services [BBW09]. Die Implementierung serviceorientierter Architekturen (SOA) bringt aber auch eine Reihe von Herausforderungen mit sich. Die flexible Orchestrierung der Services erhöht die Komplexität des gesamten Systems deutlich und kann sogar zu einer Verschlechterung der Performance führen [Ra06]. Eine SOA-Governance, d.h. ein holistisches Management der Technologie sowie der Geschäftsprozesse ist daher notwendig [Be06]. Ein Ziel dieser SOA-Governance ist es, „to check services concerning capability, security and strategic business alignment”[Ni08]. Neben der Bewältigung der erhöhten Komplexität entstehen auf Ebene der einzelnen Services auch SOA-spezifische Gefahrenpotentiale [o.V.08]. In der Literatur finden sich bereits eine ganze Reihe von Beiträgen, die das Thema SOAGovernance behandeln und entsprechende Vorgehensweisen vorschlagen [MB06; SS07; BBW09; Bi05a; Lo08; KSH08; JG07]. [Ni08] entwickeln nach Analyse einiger der genannten Quellen ein generisches Governance-Modell. Alle genannten Ansätze adressieren dabei die Governance für eine gesamte serviceorientierte Architektur. Aspekte wie der Lebenszyklus einer SOA, die Integration neuer Services sowie Pflege und Entsorgung bestehender Services sind bei dieser Betrachtung von Bedeutung. Ein wichtiger Bestandteil des SOA-Lebenszyklus ist die Identifizierung und Gestaltung von Services, die stets am Beginn steht. Obwohl dieser Teil eine entscheidende Rolle für den Erfolg einer SOA spielt, bleibt die Auswirkung von Governance-Aspekten auf die Gestaltung einzelner Services bei den betrachteten Ansätzen ungeklärt [BG09]. In der Diskussion über Gestaltungsprinzipien von Services werden Aspekte wie Schnittstellenorientierung, Interoperabilität, lose Kopplung, Modularität und Wiederverwendbarkeit von vielen Autoren als entscheidende Merkmale einer SOA dargestellt [Er04; Jo08; Bi05b; LH07]. Zweifelsohne sind diese Merkmale kennzeichnend für eine SOA, allerdings spiegeln sie ausschließlich eine technische Betrachtungsweise einer solchen Architektur wider. Die fachliche Perspektive (basierend auf Geschäftsprozessen) ist jedoch ein wichtiger Erfolgsfaktor für die Implementierung einer SOA [DD07]. Dazu gehören auch Governance-Aspekte, die nach Ansicht der Verfasser bereits bei der Identifizierung und Gestaltung von Services beachtet werden müssen. Die Berücksichtigung von Governance-Merkmalen im Lebenszyklus eines einzelnen Services wird im Folgenden als „Service-Governance“ bezeichnet (siehe Abbildung 1). Letztere bedient sich dazu einiger Elemente der ITund SOA-Governance, stellt aber keine direkte Ableitung dar und erhebt daher auch nicht den Anspruch auf vollständige Abdeckung aller Aspekte erstgenannter Governance-Arten. Der bisher häufig verfolgten, technischen Bottom-upHerangehensweise bei der Identifizierung von Services [Na04] muss ein Top-downAnsatz vorangestellt werden, um eine wirtschaftliche und unternehmensstrategisch adäquate Service-Identifikation sicherzustellen. Die im Folgenden näher betrachtete Identifikation ist der erste Schritt einer auch von anderen Autoren geforderten, hybriden Vorgehensweise zur Identifikation von Services [IS05; Za05]. Kapitel 2 gibt einen Literaturüberblick und erläutert vorhandene Methoden zur ServiceIdentifikation und zur Unterstützung der SOA-Governance. In Kapitel 3 werden aus den Kernbereichen der IT-Governance, den sogenannten IT Governance Focus Areas, Dimensionen einer Service-Governance abgeleitet. In Kapitel 4 wird anhand dieser Dimensionen ein Fragebogen entwickelt, der die Berücksichtigung von Governance-Aspekte bereits während der Service-Identifikation und -Gestaltung unterstützen soll. Dieser Fragebogen dient der methodischen Unterstützung der Service-Identifikation und ist ein erster Schritt hin zu einer Methode zur fachlichen Identifikation von Services. Kapitel 5 zieht ein Fazit und erörtert Möglichkeiten weiterer Forschung. 2 Bisherige Ansätze zur Service-Identifikation und -Gestaltung In der Literatur werden bereits einige Ansätze sowohl zur Identifikation als auch zur Gestaltung von Services diskutiert. Einige von ihnen haben ihre Wurzeln im stark ingenieurtechnisch geprägten Bereich der Fertigungsindustrie [KKB07], andere betrachten die Modularisierung im IT-Dienstleistungsbereich [BK05]. Diese Ansätze sind oft primär technisch geprägt. Auch unter den Ansätzen, die sich mit Finanzdienstleistungen beschäftigen, gibt es neben deutlich fachlich orientierten Varianten [Ar08; KA07] auch stark technische (objektorientierte) Ansätze [Wi07]. Klose et al. [KKB07] betonen die große Bedeutung des „business point of view“. Dementsprechend sind das Business Process Modeling (BPM) und die daraus resultierenden Geschäftsprozesse Grundlage ihrer Analyse. Die von ihnen betrachteten Aspekte wie beispielsweise IT-Unterstützung der Prozesse, beteiligte Organisationseinheiten, interne und externe Stakeholder sowie die Einbeziehung mehrerer Ebenen (von der Geschäftsprozesssicht bis zur Aktivitätensicht) sind von entscheidender Bedeutung für eine Identifikation von Services. Die Betrachtung der Interaktionsund Sichtbarkeitslinie, die ursprünglich aus der Marketing-Literatur stammt [Sh81], geschieht auch unter fachlichen Gesichtspunkten. Sie ist weniger für die Identifikation selbst, als vielmehr für den späteren Umgang mit den einzelnen Services entscheidend. Beide Merkmale sind für Sourcing-Entscheidungen bezüglich der Services von großer Bedeutung. Die Autoren betrachten zwar Services eines Fertigungsbetriebes, jedoch ist die Berücksichtigung der Interaktionsund Sichtbarkeitslinie für Dienstleistungsprozesse nicht minder bedeutungsvoll. Eine Stärke des Ansatzes von [KKB07] ist, dass nach der bisherigen Topdown-Vorgehensweise auch die Umsetzbarkeit der identifizierten Service auf Basis technischer Kriterien (also „Bottom-up“) geprüft wird. Sie verfolgen demnach einen hybriden Ansatz, wie er beispielsweise von [IS05] und [Za05] vorgeschlagen wird. Diese Machbarkeitsprüfung ist im Rahmen der Gestaltung von Services für eine betriebswirtschaftlich sinnvolle Implementierung dergleichen unverzichtbar. Die Notwendigkeit von IT-Governance ist in diesem Ansatz nur implizit beschrieben. Eine SOAGovernance im Speziellen fehlt vollständig. Verbunden damit werden auch bei der Identifikation von Services keinerlei Governance-Aspekte beachtet. Ein herausragendes Merkmal bei Böhmann und Krcmar [BK05] ist die ausgeprägte Zielbestimmung, deren Ergebnis allerdings den allgemeinen SOA-Zielen gleicht [Pa03]. Aus ihren Ausführungen wird nicht deutlich, inwieweit diese Zielbestimmung der Service-Identifikation nützt. Es gibt keinen expliziten Bezug zu BPM. Die Autoren erwähnen lediglich, dass vorhandene Informationen wie beispielsweise Prozessmodelle für die weitere Vorgehensweise bereitzustellen sind. Tatsächlich erfolgt später eine Dokumentation der Serviceprozesse, die zumindest implizit auf die Bedeutung von Geschäftsprozessen hinweist. Mit der Anwendung ihrer Modularisierungsmatrix verfolgen [BK05] eine hybride Herangehensweise, die allerdings deutlich mehr durch die vorhandene Technik geprägt wird als der zuvor diskutierte Ansatz von Klose et al. Mit Hilfe der Matrix soll eine komplette Architektur entworfen werden, ohne dass die Identifikation der einzelnen Serviceprozesse näher erläutert wird. Insgesamt liegt der Schwerpunkt auf der Modularisierung von IT-Dienstleistungen, so dass die hier beschriebenen Services sehr komplex sind. Auch bei [BK05] fehlt eine explizite Behandlung von ITund SOAGovernance-Aspekten. Insofern lassen sich nur wenige Aspekte für weitere Überlegungen im Rahmen der Service-Identifikation nutzen. Einer davon ist sicherlich die große Bedeutung, die die Autoren der Nachfragerintegration zukommen lassen, denn die Interaktion mit Kunden hat erheblichen Einfluss auf verschiedene Governance-Aspekte eines Services. Obwohl Winkler [Wi07] ausgehend von Geschäftsprozessen einen Top-down-Ansatz verfolgt, weist sie nicht ausdrücklich auf die Bedeutung des BPM hin. Implizit werden dennoch modellierte Prozesse aus dem Finanzdienstleistungsbereich für die Identifikation der Services verwendet. Die Autorin verzichtet im Gegensatz zu den vorher beschriebenen Ansätzen auf einen Bottom-up-Ansatz bzw. eine hybride Herangehensweise. Umso erstaunlicher ist es, dass die von ihr identifizierten Services mit Abstand am granularsten sind. Nach Ansicht des Verfassers handelt es sich bei der von Winkler beispielhaft angeführten Nullstellenberechnung nicht um einen fachlichen Service im Rahmen einer SOA, sondern vielmehr um ein Objekt im Sinne der objektorientierten Programmierung [Za05; El07]. Die Anforderungen sind sehr allgemein gehalten und beziehen sich eher auf technische Merkmale denn auf fachliche oder betriebswirtschaftliche Anforderungen. Die Erfüllung ihrer ersten Anforderung – der übergreifenden Einsetzbarkeit des Services in einer Vielzahl heterogener Anwendungen – macht [Wi07] nicht von dem (fachlich) identifizierten Service selbst, sondern von seiner (eher technisch getriebenen) Gestaltung abhängig. [Wi07] betrachtet weder ITnoch SOA-Governance bei ihrer Methode zur Service-Identifikation. Arsanjani et al. [Ar08] verfolgen einen hybriden Ansatz und demonstrieren die beispielhafte Anwendung ihrer Methode an einem Finanzdienstleistungsunternehmen. Bei ihrem Goal Service Modelling und der darauf folgenden Zerlegung handelt es sich ebenfalls um eine hierarchische Dekomposition der Geschäftsprozesse. Es ist also zunächst ein klassischer Top-down-Ansatz, der mit den zuvor präsentierten Verfahren vergleichbar ist. Spätestens im Rahmen der Spezifikation bewegt sich der Fokus aber hin zur technischen Umsetzung und bezieht die bereits bestehende Infrastruktur mit ein (Bottom-up). Zwar erinnert die Aufteilung in Identifikationsund Spezifikationsphase stark an Winklers Vorgehensweise, jedoch wird der Begriff „Service“ hier stets mit Blick auf Geschäftsprozesse, d.h. deutlich grobgranularer verwendet. Die Autoren verwenden die Begriffe „Service“ und „Web Service“ synonym, ohne explizit darauf einzugehen. Im Rahmen des Business Process Modeling führen [Ar08] eine „Rules and Policies Analysis“ durch. Diese internen Regeln und Vorschriften sind Bestandteil der IT-Governance. Die Autoren stellen auch ein fraktales Lebenszyklusmodell serviceorientierter Architekturen vor, zu dem auch die Service-Identifikation zählt. Nichtsdestotrotz findet eine Bezugnahme auf Governance-Aspekte während der Service-Identifikation nicht statt. Die von Kohlmann und Alt [KA07] vorgeschlagene Vorgehensweise gehört ebenfalls zu den hybriden Varianten der Service-Identifikation. Zusätzlich zur Business-Sicht mittels Business Process Modeling wird eine Asset Analysis für das Clustering der Services verwendet. Die Autoren unterscheiden explizit drei Service-Granularitäten und ordnen diese verschiedenen Hierarchieebenen zu. Tendenziell unterstützen ihre Services ganze Geschäftsprozesse. Im Rahmen der IT-Governance betonen [KA07] die Bedeutung der konsistenten Benennung von Services. Es findet eine Unterscheidung zwischen ausschließlich intern genutzten Services und extern bereitgestellten Services statt. Somit werden Sourcing-Optionen explizit berücksichtigt. Die Einbeziehung der funktionalen und semantischen Ähnlichkeit beim Clustering dient der betriebswirtschaftlichen Betrachtung beim Zuschnitt der Services. Neben der bereits erwähnten internen Policies finden auch gesetzliche Bestimmungen bei der Ausgestaltung der Services Berücksichtigung. [KA07] thematisieren den Umgang mit Kundendaten, die unter Umständen gesetzlich geschützt sind und daher spezieller Behandlung bedürfen. Neben gesetzlichen Regelungen spielen bei ihnen auch IT-Governance-Aspekte eine Rolle. Vor allem bei der Benennung der Services wird die Bedeutung der Governance deutlich. Bei der Gestaltung der Services werden allerdings keine dieser Aspekte berücksichtigt. Kohlborn et al. [KKCR09] unterscheiden in ihrem Ansatz Business Services und Software Services. Diese Zweiteilung greift im Grunde die auch in anderen Ansätzen vorhanden zweistufige Hierarchie von Services auf. Allerdings gelingt es den Autoren durch diese explizite Trennung deutlich besser, zunächst Business Services mit einem klaren Fokus auf Geschäftsprozesse und Berücksichtigung der Unternehmensstrategie in drei Phasen zu identifizieren. Erst anschließend werden in entsprechenden drei Phasen die unterstützenden Software Services identifiziert und durch eine „Verbindungsphase“ mit den Business Services zusammengeführt. Dieser Ansatz berücksichtigt und beseitigt eine Reihe von Schwächen anderer Herangehensweisen, bezieht aber auch ausdrücklich Ideen aus diesen mit ein. So nutzen die Autoren eine Analysetechnik, die alle Stakeholder und deren Integration berücksichtigt und lehnen sich dabei eng an [KKB07] an. Eine Berücksichtigung von Governance-Aspekten findet allerdings auch in dieser Methode nicht statt. Schelp und Stutz [SS07] sehen den Aufbau einer ganzheitlichen SOA-Governance als unumgänglich um der Steigerung der Komplexität Rechnung zu tragen. Sie stellen fest, dass ohne geeignete Governance-Instrumente, die aus einer SOA resultierende Komplexität „zu Strukturen führt, deren Wartung und Pflege ähnlich aufwendig wird wie die der bestehenden evolutionären Applikationslandschaften, die sie ablösen sollen“ [SS07, S.66]. Das von [SS07] entwickelte SOA-Governance-Modell enthält Aktivitäten für eine erfolgreiche SOA-Umsetzung, etwa Planung, Implementierung, Wartung oder Controlling. Sie benennen unter anderem die Aktivitäten SOA Service Design und SOA Service Build. Dort werden zunächst Designrichtlinien festgelegt, bevor der Service gemäß den bestehenden Entwicklungsparadigmen umgesetzt wird. Jedoch ist Governance in ihrem Verständnis auf einer höheren Ebene angesiedelt. Die Umsetzung von Governance für Services wird nicht thematisiert. Johannsen und Goeken [JG07] betonen, dass für eine SOA nahezu die gleichen Anforderungen und Herausforderungen gelten, wie sie in der IT-Governance, insbesondere im Umfeld des COBIT-Referenzmodells, mit dem Begriff „IT Governance Focus Areas“ beschrieben werden. Sie erläutern kurz die fünf Focus Areas aus SOA-Sicht, bspw. für den Bereich „Value Delivery“: „Die Erwartung an die jeweiligen Wertbeträge der Servicekomponenten unter Berücksichtigung unterschiedlicher Sourcing-Optionen ist kontinuierlich zu überprüfen.“ [JG07, S.193]. Für eine SOA-Governance zeichnen sich laut [JG07] die zwei zentralen Aufgabenbereiche SOA-Conformance und SOA-LifecycleGovernance ab. Der Bereich SOA-Conformance beinhaltet Aufgaben die zeitlich betrachtet vor der Identifikation und Gestaltung von Services liegen, etwa inwieweit ein Unternehmen organisatorisch, prozessual und technisch auf die Umstellung zur Serviceorientierung vorbereitet ist. SOA-Lifecycle-Governance beschäftigt sich mit der Gewährleistung von Governance im laufenden Betrieb. Hierfür sind die ServiceKomponenten während des SOA-Lebenszyklus gemäß den IT Governance Focus Areas (siehe Kapitel 3) einer Überprüfung zu unterziehen. Eine konkrete Ausgestaltung dieser Überprüfung wird jedoch nicht vorgenommen. [JG07] thematisieren den Zusammenhang zwischen IT-Governance und der Governance einer serviceorientierten Architektur. Eine konkrete Operationalisierung für die Umsetzung von Governance für SOA sowie eine explizite Verbindung zu einer ServiceGovernance fehlt jedoch in den genannten Ansätzen [BG09]. An dieser Stelle setzt der vorliegende Beitrag an und unterscheidet hierfür zwischen SOA-Governance und Service-Governance. Der Scope dieses Beitrags ist in Abbildung 1 hervorgehoben.